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Current  simulation  event  engineers  have 
a  range  of  architectural  capabilities 
open  to  them.  They  can  select  a 
“minimalist”  intercommunication  ar¬ 
chitecture,  providing  little  more  than  a 
communications  service,  or  they  can  utilize  a  more 
complex  architecture  featuring  multiple  advanced 
services  such  as  time  and  data  management.  They 
can  also  choose  to  rely  on  multiple  architectures,  as 
occasionally  necessitated  by  the  mix  of  simulation 
systems  that  will  be  combined  in  the  event.  However, 
mixing  architectures  is  not  easily  achieved:  bridges 
must  be  installed,  gateways  developed,  and  data 
exchange  models  (i.e.,  object  models)  rationalized  and 
composed.  The  additional  effort  required  to  employ 
mixed  architectures  is  “over  and  above”  that  necessary 
to  join  the  simulations  systems,  which  use  a  common 
architecture,  and  is  frequently  viewed  as  a  baseless 
requirement  that  would  be  unnecessary  except  for  the 
multiple  architectures  involved.  As  a  result,  the  Office 
of  the  Secretary  of  Defense  (OSD)  Modeling  and 
Simulation  (M&S)  Steering  Committee  commissioned 
a  study  to  examine  various  aspects  of  M&S  develop¬ 


ment  and  make  recommendations  that  could  improve 
architecture  interoperability. 

The  Live,  Virtual,  Constructive,  Architecture  Road¬ 
map  (LVCAR)  study  began  in  April  2007.  The  M&S 
Steering  Committee  recognized  that  M&S  capability 
had  greatly  advanced,  routinely  enabling  the  linkage  of 
critical  resources  through  distributed  architectures.  In 
part,  the  success  was  predicated  on  an  iterative  and 
evolutionary  development  of  the  intercommunication 
architectures,  including  progressive  capabilities  en¬ 
hancements  supporting  more  varied  application  of  the 
technologies  across  expanding  user  domains.  While  the 
architectures  displayed  impressive  capability  to  meet 
needs  as  designed,  they  were  not  implemented  with  a 
focus  on  ensuring  architectural  compatibility.  Thus, 
each  requirement  to  connect  systems  using  different 
architectures  within  a  single  simulation  event  was 
accompanied  by  substantial  design  and  engineering 
effort  to  achieve  cross-architecture  interoperability. 
Given  this  environment,  the  LVCAR  study  was 
chartered  to  “...  methodically  and  objectively  develop 
a  recommended  roadmap  (way  forward)  regarding 
LVC  interoperability  across  three  broad  areas  of 
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concern:  notional  definition  of  the  desired  future 
architecture  standard,  the  desired  business  model(s), 
and  the  manner  in  which  standards  should  be  evolved 
and  compliance  evaluated.”  (Henninger  et  al.  2008) 

Study  emphasis  was  placed  on  analysis  of  the 
technical  options  that  could  achieve  or  make  transpar¬ 
ent  architecture  interoperability.  The  analyses  were 
influenced  by  several  characteristics  of  the  operating 
environment.  A  fundamental  observation  was  that  the 
user  communities  expressed  little,  if  any,  complaint 
that  architectural  capabilities  were  lacking;  the  multi¬ 
architecture  state  not  only  provided  a  high  level  of 
support  across  a  diverse  user  community  but  also 
allowed  a  degree  of  user  choice  in  selecting  the 
architecture  that  best  balanced  cost  and  capability 
within  the  context  of  a  specific  application.  Moreover, 
connecting  the  different  architectures  together  was  a 
tractable  problem  with  which  the  community  had 
developed  a  base  of  expertise  and  resources,  albeit 
nonoptimal.  The  study  also  concluded  that  the  cost  of 
switching  applications  to  use  of  different  architectures 
was  high,  often  prohibitive  at  the  level  where  costs 
would  be  borne.  Thus,  any  unfunded  mandate 
directing  users  to  change  architectures  would  likely 
be  ignored.  Further,  no  existing  business  or  manage¬ 
ment  tools  could  enforce  such  mandates.  In  this 
context,  the  study  concluded  that  fundamental  change 
either  to  the  number  of  available  architectures  or  to  the 
architectures  themselves  was  not  warranted  or  desir¬ 
able.  Finally,  the  implementation  of  a  new,  “improved 
replacement”  architecture  would  only  introduce  yet 
another  architecture  requiring  integration,  effectively 
degrading  interoperability. 

Based  on  these  characterizations  of  the  problem,  the 
study  recommendations  emphasized  a  two-front  phi¬ 
losophy.  First,  near-term  actions  were  necessary  to  ease 
the  problem  of  architecture  integration.  Integration 
should  be  made  transparent,  so  that  users  would 
interact  with  a  seamless  “architecture  of  architectures.” 
Second,  a  longer-term  goal  emphasized  an  evolution¬ 
ary  process  of  Common  Training  Instrumentation 
Architecture  (CTIA),  High-Level  Architecture 
(HLA),  and  Test-Training  Enabling  Architecture 
(TENA)  architectural  convergence.  Individual  actions 
supporting  both  strategies  are  now  ongoing. 

The  current  LVCAR  Implementation  (LVCAR-I) 
program  is  the  follow-on  effort,  concentrating  on  five 
tasks  designed  to  address  specific  recommendations 
identified  in  the  original  LVCAR  report.  These  five 
tasks  include  LVC  Common  Capabilities,  LVC 
Architecture  Convergence,  Common  Gateways  and 
Bridges,  Joint  Composable  Object  Model  QCOM) 
Development,  and  Managing  the  LVC  Environment. 


LVCAR-I  project  overview 

The  project’s  aim  is  to  explore  organizational  and 
structural  (e.g.,  use  of  standards)  options  to  better  (a) 
manage  LVC  architecture  interoperability;  (b)  create 
reference  models  to  focus  data  and  service  reuse  efforts; 
(c)  reduce  LVC  architecture  divergence  and  tool 
proliferation;  and  (d)  explore  emerging  technology 
issues  related  to  future  LVC  architecture  performance 
and  requirements.  The  planning,  development,  and 
execution  of  LVC  events  are  universally  recognized  to 
be  expensive  by  any  measure.  Also,  the  M&S 
community  lacks  the  agility  to  support  unforeseen 
events  without  great  difficulty.  Given  this  situation, 
the  objective  of  LVCAR-I  is  to  reduce  overhead  and 
thus  improve  the  ability  to  construct  and  conduct 
timely  LVC  events.  Described  another  way,  the  goal 
for  LVCAR-I  is  to  get  M&S  support  inside  the 
military  operations  decision  cycle. 

The  project  leads  have  taken  a  holistic  approach  to 
organization  and  definition  of  an  acquisition  strategy. 
Fundamentally,  LVCAR-I  is  designed  to  work  in  an 
environment  where  there  are  many  different  factors 
and  incentives  that  influence  decisions,  including 
willingness  to  change  and  the  adoption  of  technical 
solutions.  Understanding  these  factors  and  their  effects 
are  as  important  to  the  success  of  the  project  as  the 
technology  advances  themselves.  As  a  result,  the 
LVCAR-I  team  distilled  the  19  recommendations 
found  in  the  LVCAR  study  to  the  grouping  of  core, 
affiliated,  and  supporting  efforts  as  described  in 
Table  1. 

Core  task  organization  and  grouping 

Beginning  in  Fiscal  Year  2009  (FY09),  a  team  led  by 
the  Johns  Hopkins  University/ Applied  Physics  Labo¬ 
ratory  ( JHU/APL)  initiated  efforts  to  implement  the 
LVC  Architecture  Roadmap.  The  overall  organization 
of  the  effort  is  shown  in  Figure  1. 

This  particular  organization  was  designed  to  reflect 
the  blended,  two-front  strategy  defined  in  the  Road¬ 
map.  “LVC  Common  Capabilities”  and  “Common 
Gateways  and  Bridges”  focus  on  improvements  in  the 
processes,  tools,  and  supporting  resources  used  to 
develop  LVC  environments  in  the  near-to-mid  term. 
“LVC  Architecture  Convergence”  focuses  on  mid-to- 
long-term  actions  to  prevent  further  divergence  (and 
facilitate  convergence)  among  the  major  simulation 
architectures  in  wide  use  across  the  Department  of 
Defense  (DoD)  today.  In  addition,  the  “Managing  the 
LVC  Environment”  task  is  designed  to  identify 
existing  business  models  and  management  structures 
for  each  of  the  major  simulation  architectures,  assess 
the  relative  strengths  and  weaknesses  of  each,  and 
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Table  1.  Overview  of  live,  virtual,  constructive,  architecture  roadmap — implementation  efforts. 


Core  task 

Affiliated  task 

Supporting  task 

Standards 

development 

Systems  engineering  process 
Federation  agreement  templates 
Reusable  development  tools 

Asset  reuse  mechanisms 

Software 

development 

Common  gateways  and  bridges 
Architecture  convergence 

Joint  composable  object  model 

Studies 

Management — product  transition 

Management  organizations  and 

SOA  concepts 

strategy 

processes 

LVC  futures 

Outreach 

Core  task  workshops 

Management  workshops 

M&S  forums/presentations 
Working  group  presentations 
Web-based  information 

SOA,  service-oriented  architecture;  LVC,  live,  virtual,  constructive;  M&S,  modeling  and  simulation. 


recommend  some  potential  realignments  to  improve 
efficiency  and  reduce  maintenance  costs  in  the  future. 

The  following  sections  describe  the  rationale  and 
objectives  associated  with  these  three  main  technical 
areas  of  LVCAR-I  tasking,  and  delineates  the  specific 
activities  being  performed  within  each  area. 

Core  task:  LVC  common  capabilities.  During 
LVCAR  development,  it  was  recognized  that  the 
absence  of  supporting  products  was  creating  an 
unnecessarily  heavy  burden  on  developers  of  multi¬ 
architecture  LVC  simulation  environments.  This 
increased  the  technical  and  cost  risks  inherent  to  the 
LVC  development  process  and  adversely  affected  LVC 
interoperability.  LVCAR  workshops  were  held  with 
users  and  developers  of  multi-architecture  environ¬ 
ments  to  assist  in  the  identification  of  necessary 
products  and  to  estimate  the  return  on  investment 
associated  with  implementing  these  products.  Based  on 


Figure  1.  Organization  for  live,  virtual,  constructive, 
architecture  roadmap  implementation. 


the  assessment  of  workshop  feedback,  four  categories 
of  products  were  identified  as  having  the  highest  value 
to  the  LVC  community,  as  summarized  below. 

Systems  engineering  process.  When  user  communi¬ 
ties  of  different  simulation  architectures  must  develop  a 
unified  multi-architecture  distributed  simulation  envi¬ 
ronment,  the  different  development  processes  native  to 
each  user  community  can  create  barriers  to  effective 
collaboration.  For  multi-architecture  LVC  develop¬ 
ment  to  be  successful,  the  communities  aligned  with 
the  different  simulation  architectures  need  to  work 
together  toward  common  goals;  differences  in  the 
practices  and  procedures  inherent  to  these  communi¬ 
ties  can  lead  to  misunderstandings,  misinterpretations, 
and  general  confusion  among  team  members.  The  key 
product  identified  to  address  this  problem  was  a 
common  systems  engineering  process  for  the  develop¬ 
ment  and  execution  of  multi -architecture  simulation 
environments. 

Rather  than  develop  a  whole  new  process,  this  task 
leverages  an  emerging  Institute  of  Electrical  and 
Electronic  Engineers  (IEEE)  process  standard  (IEEE 
1730)  as  a  framework  onto  which  multi-architecture 
issues  and  solutions  can  be  overlaid.  This  framework,  the 
Distributed  Simulation  Engineering  and  Execution 
Process  (DSEEP),  tailors  best  practices  in  the  systems 
and  software  engineering  communities  to  the  domain  of 
distributed  simulation.  The  DSEEP  defines  the  se¬ 
quence  of  activities  to  develop  and  execute  distributed 
simulation  environments  in  an  architecturally  neutral 
manner  (Figure  2).  Using  this  framework,  the  key 
technical  issues  associated  with  multi-architecture  de¬ 
velopment  are  aligned  with  the  activities  within  the 
process,  and  user  guidance  is  provided  on  how  to  address 
each  issue  based  on  existing  community  practices. 

Upon  completion  of  the  Systems  Engineering 
Process  task,  IEEE  standardization  is  expected  to 
commence.  Given  the  close  ties  to  the  DSEEP,  the 
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Figure  2.  Distributed  simulation  engineering  and  execution  process  top-level  process  flow. 


Systems  Engineering  Process  is  expected  to  become  the 
first  officially  recognized  DSEEP  overlay  (i.e.,  IEEE 
1730.1).  Other  supporting  overlays  are  expected  in  the 
near  future  (e.g.,  verification,  validation  and  accredi¬ 
tation,  test  and  evaluation)  to  provide  additional  LVC 
community  support. 

Federation  agreement  templates.  Many  agreements 
must  be  established  for  an  LVC  simulation  environ¬ 
ment  to  function  properly.  Examples  include  reference 
frames,  shared  databases,  entity  enumerations,  and 
supporting  tools  such  as  loggers  and  viewers.  In  multi¬ 
architecture  LVC  environments,  there  is  an  even 
broader  list  of  agreements  that  must  be  negotiated, 
including  execution  management  mechanisms,  gate¬ 
ways,  and  supporting  middleware.  Unfortunately,  there 
is  no  cross-architecture  standard  for  the  content  or 
format  of  federation  agreements;  these  agreements  are 
usually  local  conventions  or  are  completely  ad  hoc. 
This  implies  that  multi-architecture  LVC  initiatives 
must  continuously  recreate  the  types  of  information  or 
products  requiring  cross-architecture  agreements,  in¬ 
creasing  development  time,  and  introducing  the 
possibility  of  missed  agreements.  The  lack  of  a 
standard  template  for  federation  agreements  also 
adversely  affects  the  reusability  of  the  agreements 
between  programs. 

The  purpose  of  the  Federation  Agreements  Tem¬ 
plate  task  is  to  develop  an  architecture-independent 
template  for  establishing  federation  agreements,  along 
with  potential  architecture-specific  extensions.  The 
content  and  format  of  the  emerging  template  is  based 
on  examples  of  federation  agreements  documents 
developed  to  support  programs  across  the  DoD  and 
represents  a  reconciliation  of  the  varying  interests  of 
the  different  architecture  communities.  The  template  is 
expressed  in  an  Extensible  Markup  Language  (XML) 
schema,  enabling  machine-readable  interchange  of 
federation  agreement  data.  In  the  future,  a  tool  will 
be  developed  that  implements  the  schema  and  provides 
some  degree  of  automation  for  all  users  of  this  product. 

Reusable  development  tools.  Every  step  in  the 
process  of  distributed  simulation  development  includes 


many  opportunities  for  automation.  These  include 
utilities  such  as  requirements  development  tools, 
scenario  development  tools,  conceptual  and  object 
modeling  tools,  testing  tools,  and  after  action  review 
tools.  While  these  tools  satisfy  most  functional  needs,  a 
wide  range  of  business  models  are  used  across  the  tool 
spectrum,  including  government  off  the  shelf,  com¬ 
mercial  off  the  shelf,  and  proprietary  solutions 
(Figure  3).  This  is  a  significant  impediment  to  sharing 
of  tools,  especially  for  multi-architecture  development. 
The  varying  formats  used  by  these  tools  to  store  and 
exchange  data  are  yet  another  impediment  to  reuse  of 
tools  across  architectural  boundaries. 

The  purpose  of  this  task  is  to  examine  the  various 
business  model  options  associated  with  efficient 
sharing  of  tool  resources  for  LVC  simulation  applica¬ 
tions,  identify  the  most  beneficial  approach,  and 
implement  that  approach  in  a  phased,  controlled 
fashion  driven  by  the  areas  of  greatest  need.  The  main 
product  of  this  activity  is  an  identified  set  of  LVC 
development  tools  that  are  reusable  across  different 
architectures  along  with  supporting  business  models 
for  tool  distribution  and  maintenance.  The  other 
product  of  this  activity  is  a  set  of  architecture- 
independent  formats  for  data  storage  and  exchange 
across  architectures. 

/Asset  reuse  mechanisms.  There  are  currently  several 
repositories  and  registries  in  use  across  the  DoD.  The 
main  clearinghouse  for  M&S  information  is  the 
Modeling  and  Simulation  Information  Analysis  Center 
(MSIAC).  The  Services’  Modeling  and  Simulation 
Resource  Repository  is  accessible  through  the  MSIAC, 
thus  allowing  a  wide  range  of  search  capabilities  relevant 
to  developing  or  employing  M&S  applications.  How¬ 
ever,  estimates  of  utilization  indicate  that  there  are 
relatively  few  users,  and  the  level  of  M&S  asset  reuse 
appears  to  be  much  lower  than  desired. 

The  purpose  of  this  task  is  to  examine  existing  DoD 
repository  and  registry  capabilities  for  M&S  reuse. 
This  includes  sponsored  reuse  initiatives  such  as  M&S 
catalogs  and  metadata  discovery  specifications.  The 
product  of  this  task  is  a  plan  of  actions  and  activities  to 
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Figure  3.  Live,  virtual,  constructive  development  tool  business  models. 


better  support  the  reuse  of  LVC  assets  across  the 
Department.  This  plan  not  only  identifies  basic 
infrastructure  improvements  but  also  provides  recom¬ 
mendations  on  supporting  processes  and  business 
incentives  based  on  an  analysis  of  the  causes  behind 
programs  “building  new”  rather  than  reusing  existing 
capabilities. 

Core  task:  common  gateways  and  bridges.  The 
second  major  category  of  LVCAR-I  core  tasks 
examines  common  gateways  and  bridges.  These  are 
essential  elements  that  link  disparate  LVC  assets  and 
translate  across  multiple  protocols  in  multi-architecture 
environments.  However,  there  are  several  persistent 
problems  that  result  in  barriers  to  cross-architecture 
interoperability.  Many  of  these  issues  stem  from  the 
lack  of  standard  mechanisms  supporting  gateway 
capability  discovery,  configuration,  and  employment. 
Thus,  many  project  managers  find  it  much  easier  to 
simply  build  their  own  gateways,  specifically  tailored  to 
their  specific  application,  rather  than  attempt  to  reuse 
existing  gateway  assets.  This  has  resulted  in  a  large 
number  of  program-specific  gateways  that  are  not 
reusable  outside  of  their  design  context.  This  is  grossly 
inefficient  from  a  corporate  perspective,  as  not  only 
does  the  government  pay  over  and  over  again  to  build 
the  same  basic  gateway  capabilities,  but  it  also  pays  for 
the  maintenance  of  a  large  number  of  redundant 
gateways. 

The  purpose  of  this  task  is  to  develop  supporting 
products  that  improve  efficiency  and  effectiveness  related 
to  gateway  use.  The  task  involved  an  early  outreach 
activity  to  characterize  existing  gateways  according  to  a 
defined  set  of  features.  This  provided  an  early  glimpse  of 
the  requirements  that  could  be  met  through  existing 
gateways.  While  this  identified  a  small  number  of 
capability  gaps,  it  also  brought  out  the  high  degree  of 
redundancy  among  current  gateways.  Next,  a  strategy  was 
developed  to  discourage  new  gateway  development  while 
making  existing  gateways  more  accessible  and  easier  to 
use.  The  fundamental,  enabling  tasks  that  collectively 
define  this  strategy  can  be  summarized  as  follows: 


•  A  common  Gateways  Description  Language, 
which  allows  for  the  description  of  gateway 
capabilities  in  a  machine-readable  form.  This 
allows  gateway  users  to  discover  needed  capabil¬ 
ities  via  automated  means  rather  than  manual 
searches  of  gateway  documentation. 

•  A  set  of  Gateway  Performance  Benchmarks,  which 
provides  a  common  way  of  assessing  the  relative 
ability  of  competing  gateways  to  provide  needed 
capabilities. 

•  A  common  Gateway  Configuration  Model,  which 
provides  a  standard  means  of  initializing,  tailor¬ 
ing,  and  configuring  gateways. 

Efforts  to  begin  all  three  of  these  products  have  been 
initiated.  Tools  to  implement  these  specifications  are 
expected  to  be  developed  in  the  FY12  timeframe. 

Core  task:  LVC  architecture  convergence.  There  is  a 
general  consensus  within  the  LVC  community  that 
some  degree  of  convergence  among  the  major  simu¬ 
lation  architectures  would  be  beneficial.  Adjudication 
of  architectural  differences,  even  if  it  can  only  be 
achieved  for  some  service  categories  and  only  between 
certain  architectures,  would  reduce  efforts  to  imple¬ 
ment  potentially  ad  hoc  cross- architecture  solutions 
during  LVC  developments  and  generally  improve 
LVC  interoperability.  However,  there  are  many 
barriers  to  achieving  architecture  convergence.  While 
there  are  certainly  technical  challenges,  the  business 
model  and  management  challenges  are  even  more 
formidable.  The  full  range  of  these  challenges  must  be 
addressed  for  any  viable  architecture  convergence 
strategy  to  succeed. 

The  purpose  of  this  task  is  to  examine  the  issues  and 
risks  related  to  architecture  convergence  and  to  develop 
an  evolutionary  strategy  to  achieve  convergence.  The 
task  required  an  analysis  of  existing  simulation 
architectures  to  identify  candidates  for  convergence, 
followed  by  an  assessment  of  the  implementations  of 
the  various  architecture  services  to  determine  exactly 
how  and  where  to  target  convergence  activities.  Finally, 
convergence  options  were  identified  and  evaluated 
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Figure  4.  Common  simulation  infrastructure  concept. 


from  the  technical,  business,  and  management  per¬ 
spectives.  Recommendations  on  subsequent  conver¬ 
gence  activities  are  made  as  part  of  this  assessment. 

A  key  aspect  of  the  convergence  task  is  to  categorize 
simulation  architecture  services  into  those  that  are 
architecture  specific  (i.e.,  do  not  need  to  be  interop¬ 
erable  between  architectures  for  multi-architecture 
events  to  operate  properly)  and  those  that  are 
“functionally  similar”  across  the  architectures.  The 
functionally  similar  services  are  candidates  for  becom¬ 
ing  “converged”  services,  which  must  be  aligned  for  the 
architectures  to  work  together  without  loss  of  func¬ 
tionality.  Three  alternatives  for  implementing  the 
converged  services  have  been  considered: 

•  Establish  a  wire  standard  defining  how  all 
simulation  architectures  communicate  data; 

•  Establish  a  static  application  programmer’s  inter¬ 
face  and  implementation  of  the  converged 
services;  and 

•  Build  a  shared  implementation  of  the  converged 
services,  referred  to  as  the  Common  Simulation 
Infrastructure  (CSI). 

Figure  4  illustrates  how  the  CSI  concept  would 
work.  All  architecture-specific  communication  would 
take  place  via  the  same  middleware  services  that  the 
simulations  currently  use.  However,  the  middleware 
would  communicate  through  the  CSI  for  all  “con¬ 
verged  functionality”  communication  with  other  sim¬ 
ulations.  The  CSI  would  automate  the  alignment 
across  the  converged  services  so  that  effective  and 
direct  interaction  among  simulations  employing  inter¬ 
faces  from  different  architectures  is  possible.  Note  that 
gateways  are  still  required  to  integrate  Distributed 
Interactive  Simulation  (DIS)  simulations  into  multi¬ 
architecture  LVC  environments,  due  to  the  difficulty 
of  achieving  meaningful  convergence  between  DIS  and 
other  architectures. 


Follow-on  efforts  in  the  architecture  convergence 
area  are  expected  to  focus  initially  on  socialization  of 
convergence  options  with  affected  communities,  and 
potentially  some  early  experimentation  with  a  CSI 
prototype.  Discussion  of  business  model  and  manage¬ 
ment  concerns  will  be  part  of  this  socialization  process 
to  ensure  community  support  before  progressing  down 
any  particular  convergence  path. 

Affiliated  task:  the  Joint  Composable  Object 
Model  (JCOM)  program 

The  JCOM  effort  is  being  jointly  sponsored  by  the 
Joint  Forces  Command  and  the  Modeling  and 
Simulation  Coordination  Office.  The  effort  will  result 
in  a  repository  of  commonly  used  components  of  object 
models,  an  Architecture  Neutral  Data  Exchange 
Model  (ANDEM)  format  to  represent  those  compo¬ 
nents,  and  a  set  of  tools  to  facilitate  the  assembly  of 
those  components.  The  JCOM  effort  relies  on  an 
information-based  approach  in  that  much  of  the 
disparate  information  necessary  to  create  an  object 
model  is  both  represented  in  the  system  and  linked  to 
related  information.  That  is,  run-time  data  exchange 
between  simulation  systems  occurs  to  support  a  specific 
purpose  (e.g.,  training  for  chemical,  biological,  radio¬ 
logical,  nuclear,  and  high-yield  explosives  operations; 
acquisition  related  to  Joint  close  air  support;  planning 
for  time  sensitive  targets  missions).  Several  mission 
areas  have  been  decomposed  and  represented  in  the 
JCOM  repository,  including  links  to  related  compo¬ 
nents  of  object  models.  Users  can  exploit  these  linkages 
by  identifying  components  that  support  specific 
mission  areas  or  by  finding  the  degree  of  mission 
support  offered  by  a  specific  object  model.  JCOM  is 
the  only  utility  that  exploits  these  types  of  relationships 
between  mission  areas  and  object  model  components 
and  thus  offers  a  unique  capability  supporting  widely 
ranging  users  including  acquisition  executives,  trainers, 
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experimenters,  and  event  designers.  JCOM  also 
provides  unique  capabilities  for  event  engineers  who 
make  the  related  simulation  event  a  reality. 

Typically,  event  engineers  start  their  work  by 
adapting  solutions  to  similar  problems.  In  the  JCOM 
context,  event  engineers  start  with  the  object  models 
from  a  set  of  previously  completed  simulation  events 
that  collectively  solve  the  problem  at  hand.  The 
problem  then  becomes  one  of  composing  a  new  object 
model  from  the  existing  set  of  object  models.  This  is  a 
familiar  problem  usually  solved  at  a  “FOMorama,”  a 
meeting  of  engineers  well  versed  in  the  contents  of 
each  object  model.  Collectively,  they  are  able  to 
compose  the  different  models  into  a  single  object 
model  that  meets  the  needs  of  all  systems.  This  task  is  a 
laborious  manual  analysis  completed  by  a  group  of  very 
experienced  engineers.  JCOM  addresses  this  part  of 
the  problem  by  automatically  comparing  data  exchange 
models  (including  cross-architecture  comparisons  of 
models  from  HLA,  TENA,  CTIA,  or  DIS)  to  identify 
both  similarities  and  differences.  This  permits  the 
engineers  to  focus  their  attention  on  only  those  parts  of 
the  object  models  that  JCOM  could  not  automatically 
equate,  greatly  reducing  the  time  and  effort  to  prepare 
a  composition  that  supports  the  needs  of  all  systems. 

Supporting  task:  M&S  service-oriented 
architecture  concept  pilot — educate ,  inform, 
and  present. 

Educate  and  inform.  Service-Oriented  Architecture 
(SOA)  technology  holds  great  promise  for  addressing 
many  of  the  technical  challenges  documented  in  the 
Live  Virtual  Constructive  Architecture  Roadmap  Study. 
Where  existing  architectures  use  different  protocols  and 
interfaces,  SOA  offers  services  that  enable  composa- 
bility  of  systems  via  a  layer  of  abstraction.  Where  cur¬ 
rent  M&S  data  repositories,  such  as  terrain  databases, 
are  duplicative,  SOA  offers  the  possibility  of  services  that 
promote  reusability.  The  philosophy  of  SOA  is  con¬ 
structed  on  the  guiding  principles  of  “reuse,  granularity, 
modularity,  composability,  componentization,  and  in¬ 
teroperability”  (IBM  2004). 

However,  SOA  is  not  a  panacea.  In  particular,  using 
an  SOA  to  provide  the  interfaces  to  an  LVC 
distributed  simulation,  in  and  of  itself,  will  not  cause 
all  fundamental  problems  to  disappear.  SOA  use  can 
provide  the  scaffolding  to  address  these  issues  at  the 
time  of  design  and  initial  implementation,  easing 
future  burdens  of  functional  and  communication 
compatibility. 

There  have  been  studies  and  demonstrations  that  the 
SOA  framework  can  support  LVC  multi-architectural 
distributed  simulations.  However,  SOA  has  not  been 
embraced  by  the  M&S  community  or  by  LVC  multi¬ 


architecture  developers.  There  are  both  real  and 
perceived  up-front  costs  of  employing  a  new  technol¬ 
ogy  to  address  compatibility  issues  that  have  tradition¬ 
ally  been  addressed  with  ad  hoc  gateways  and  bridges, 
one-of-a-kind  database  connectors,  and  other  single¬ 
point  design  solutions.  Therefore,  the  objective  of  this 
effort  is  to  educate  and  inform  the  DoD  M&S 
community  of  the  benefits  and  barriers  related  to 
employing  SOA  technology. 

SOA  concept  prototype.  The  DoD  led  the  way  in 
SOA-like  architectures  such  as  HLA,  TENA,  and 
CTIA — all  of  which  built  on  the  then-emerging 
Common  Object  Request  Broker  Architecture  defined 
by  the  Object  Management  Group.  These  architec¬ 
tures  were  designed  to  integrate  enclaves  of  individual 
systems  and  are  not  optimized  to  bridge  enclaves  across 
an  enterprise.  In  contrast,  industry  has  developed 
robust  SOA-based  software  technologies  and  standards 
that  clearly  have  the  potential  to  provide  for  architec¬ 
ture  interoperability  to  interconnect  between  stand¬ 
alone  enclaves  at  the  enterprise  level  and  to  serve  as  the 
primary  infrastructure  for  common  services,  such  as 
interfaces  to  battle  command  systems  or  models  of  the 
synthetic  natural  environment. 

The  concept  of  using  the  SOA-based  software  and 
standards  in  this  mode,  as  shown  in  Figure  5,  is  not 
new  and  is  being  eyed  with  keen  interest  by  many  in 
the  simulation  industry.  However,  no  extant  program 
of  record  can  afford  to  put  their  program  at  risk 
(especially  in  the  current  high  ops  tempo  environment) 
on  an  unproven  approach,  no  matter  how  promising. 
As  an  early  step  towards  realizing  the  concept  shown  in 
Figure  5  the  “Present”  portion  of  the  M&S  SOA 
Concept  Pilot  implements  an  integrated  set  of 
supporting  simulation  services  and  creates  a  prototype 
linking  two  disparate  enclaves  using  real  federations 
and  real  simulations  along  with  a  surrogate  service 
(Figure  6). 

This  effort  will  bridge  the  Joint  Conflict  and 
Tactical  Simulation  (JCATS)  federate  in  the  Army’s 
Entity  Resolution  Federation  (ERF)  with  the  WAR- 
SIM  Intelligence  Model  (WIM)  federate  in  the 
WARSIM  federation  and  a  surrogate  service  to 
emulate  the  Order  of  Battle  System  (OBS)  to  initialize 
both  federations. 

The  prototype  will  provide  information  to  assess  the 
ability  of  SOA  to  address  the  following  LVC 
requirements: 

•  a  common  data  interchange; 

•  enclave  policy  translation; 

•  use  of  a  common  service  to  replace  equivalent 
application  (federate)  functionality;  and 

•  run-time  performance  and  scalability. 
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Figure  5.  A  hypothetical  interoperable  architecture  linking  legacy  enclaves  and  common  services. 


Supporting  task:  beyond  SOA — a  look  to  the  future 
for  U.S.  DoD  M&S.  The  purpose  of  this  task  is  to  look 
at  emerging  technologies  and  processes  that  the  DoD 
M&S  community  should  consider  in  future  develop¬ 
ment  projects.  This  is  not  intended  to  be  an  exhaustive 


study  but  rather  an  overview  with  rationale  that 
explains  why  each  technology/process  is  significant. 

Since  the  DoD  is  a  consumer,  not  a  driver  of  the 
Information  Technology  (IT)  market  place,  it  must 
make  best  use  of  the  commercial  IT  standards, 


Persistence 


Figure  6.  Proposed  prototype  for  an  interoperable  architecture  implementation  between  two  disparate  architectures. 
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practices,  and  technologies  available  to  meet  their 
needs.  Given  the  long  lead  times  that  are  typical  for 
DoD  project  initiation  (3-10  years),  the  Department 
must  have  a  long  view,  informed  by  knowledge  of 
coming  capability,  as  a  precondition  to  relying  on  best 
practices.  A  set  of  military  operational  scenarios 
covering  the  spectrum  from  high  tempo  kinetic 
operations  to  natural  disaster  relief  are  used  to  guide 
the  identification  and  application  of  these  future 
technologies.  The  technology  areas  under  consider¬ 
ation  are  divided  into  two  areas:  (a)  Development 
Components  (technical  areas  including  Mobile  Com¬ 
puting  and  Augmented  Reality,  Ubiquitous  Surveil¬ 
lance  and  Automated  Reasoning,  Event  Model  Driven 
Architectures,  and  Self-Healing  and  Self-Managing 
Systems),  and  (b)  Use  Components  (considerations 
that  affect  adoption  of  technology  including  M&S 
Social  Graphs,  The  Paradox  of  “Choice  and  Budge,” 
Mashup  Software,  and  fast,  inexpensive,  simple,  and 
tiny  (FIST),  Cloud  Encapsulation,  and  “Everything  is 
a  Game”). 

Supporting  task:  public  outreach.  Implied  missions  of 
the  LVCAR-I  project  are  to  inform  the  M&S 
community  of  project  activities  and  where  possible 
get  the  community  involved,  and  at  the  earliest 
opportunity  provide  access  to  the  project’s  products. 
The  project  team  examined  the  realm  of  possibilities  to 
meet  the  various  aspects  of  this  mission  and  decided 
that  it  was  best  to  take  a  three-pronged  approach  and 
engage  the  M&S  community  through  (a)  M&S 
forums,  (b)  working  groups,  and  (c)  electronic  and 
print  media. 

The  M&S  forums  include  presentations  at  the 
National  Defense  Industrial  Association  (NDIA)  Sys¬ 
tems  Engineering  Conference,  NDIA  M&S  Congress, 
Simulations  Interoperability  Standards  Organization 
events,  and  National  Training  and  Simulation  Associ¬ 
ation’s  Interservice/Industry  Training,  Simulation  and 
Education  Conference  (I/ITSEC).  These  opportunities 
have  provided  access  to  a  variety  of  special  use  groups 
within  the  M&S  community,  and  there  are  plans  to 
continue  using  these  opportunities  as  they  arise. 

Because  of  the  growing  emphasis  on  LVC  simula¬ 
tion  constructs  within  the  DoD,  there  are  numerous 
programs  and  projects  addressing  training,  analysis, 
testing,  and  acquisition  requirements.  Having  related 
activities  opens  the  possibility  for  these  parallel 
programs  to  provide  mutual  support  but  also  assumes 
the  M&S  community  is  cognizant  of  emerging 
developments.  To  improve  community  situational 
awareness,  the  program  manager  for  LVCAR-I 
initiated  an  LVC  Interservice  Working  Group 
(LVC-IWG)  to  provide  a  forum  where  the  leaders  of 


these  various  programs  could  share  information  about 
what  is  being  undertaken  and  look  for  opportunities  to 
leverage  each  other’s  work.  In  addition,  the  LVCAR-I 
project  has  sponsored  numerous  special  interest 
workshops  to  solicit  input  to  the  various  project 
subtasks. 

Finally,  this  project  is  providing  information 
through  articles  and  a  Web  site.  This  article  is  an 
example  of  print  media  use,  and  through  the 
sponsorship  of  Joint  Forces  Command  HarmonieWeb 
there  is  a  repository  for  publically  released  material 
from  the  LVCAR-I  project  (harmonieweb.org)  under 
the  work  group  “MSCO  HLT  SC2  LVCAR-I.” 

Next  steps 

The  initial  commitment  of  funds  for  the  LVCAR-I 
project  covered  a  24-month  period  of  performance. 
Since  inception,  a  great  deal  of  information  has  been 
gathered  and  analyzed.  As  with  many  efforts,  we 
rapidly  discovered  the  more  we  learned  led  to  logical 
steps  for  future  work  that  needs  attention.  Without 
losing  sight  that  the  goal  is  to  improve  LVC 
interoperability  by  providing  practical  tools  and 
pragmatic  approaches  to  the  problem,  the  project  will 
have  follow-on  efforts.  Planning  for  FY11  and  FY12 
includes  the  use  of  test  beds,  design  of  software, 
initiation  of  standards,  and  continued  sharing  of 
lessons  learned. 

Conclusion 

From  the  previous  material,  it  is  easy  to  see  that  the 
LVCAR-I  is  an  ambitious  project  from  both  a 
technical  and  managerial  standpoint.  While  having 
interoperability  as  the  focus  of  the  project  provides  a 
unifying  goal  and  eases  some  management  aspects, 
there  are  a  number  of  ways  to  approach  that  problem 
set  that  add  numerous  levels  of  complexity.  The 
functional  area  approach  that  underlies  the  project 
management  is  recognition  that  decisions  and  adoption 
of  technical  solutions  are  not  based  solely  on  logic  or 
cost  analysis.  Understanding  the  other  factors  that 
relate  to  the  adoption  of  technology  will  improve  the 
use  of  the  tools  developed  through  LVCAR-I.  In  the 
end,  interoperability  and  ultimately  support  to  the 
warfighter  will  improve.  □ 
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